Since the witness data cannot be updated within the prove_with_rng function (immutable reference), does the TranscriptRng need to be reinitialized multiple times within the function?

Unfortunately yes. It's built from a clone of the current Transcript state, which is updated each round. This means reinitialization is necessary to take advantage of those state changes.

It's not clear to me if they mean the TranscriptRng should be kept up to date with the witness data or if each time it is used once to generate a random number a new instance is needed (seems doubtful/doesn't make sense, but if that is the case this is not done everywhere e.g. lines 524,525 etc).

The witness data is fixed at the start of proof generation and doesn't change. The only reason it needs to be added to each TranscriptRng reinitialization is because it isn't (and can't be) part of the transcript state since it's known only to the prover. It makes it a bit awkward to use, but I get why they designed the API that way.

The linked documentation is a bit unclear when it advises reinitializing the TranscriptRng every time the protocol needs randomness. Because the transcript state is only updated between rounds, there is no advantage to reinitializing within a round. That's the approach I took: the TranscriptRng is reinitialized whenever the transcript state is updated, and used for all randomness needed during that round.

That being said, I could have made the intent more clear by including better comments and placing the reinitializations more directly at the state changes. I'll make a small update to do so, and to include your other review suggestion.

I made more changes than originally expected in order to make transcript and random number generator functionality more clear.

In particular, the previous transcript helper functions have been moved into RangeProofTranscript to abstract away the underlying Merlin transcript from the prover and verifier. I also moved RangeWitness::to_bytes out of RangeWitness and into RangeProofTranscript since the resulting byte representation is not canonical and should never directly be used outside of this specific use case.

The prover and verifier transcript operations were correspondingly simplified, and each TranscriptRng initialization now appears alongside a transcript state update.

After discussing with @hansieodendaal, it was agreed that it would be best to move the transcript RNG updates into RangeProofTranscript to ensure they aren't forgotten.

The most recent commit does this. Transcript initialization returns a RangeProofTranscript and a TranscriptRng; calls to the challenge functions update the TranscriptRng via a mutable reference.

The verifier now also uses a TranscriptRng for its random weights. This allows it to use the same API as the prover, except without passing a witness as secret data. This is still safe, since the external RNG provides entropy.